Skip to content

🪲 [Fix]: Wildcard maximum versions no longer fail module processing - #446

Merged
Marius Storhaug (MariusStorhaug) merged 6 commits into
mainfrom
fix-wildcard-maximumversion
Aug 8, 2026
Merged

🪲 [Fix]: Wildcard maximum versions no longer fail module processing#446
Marius Storhaug (MariusStorhaug) merged 6 commits into
mainfrom
fix-wildcard-maximumversion

Conversation

@MariusStorhaug

@MariusStorhaug Marius Storhaug (MariusStorhaug) commented Aug 8, 2026

Copy link
Copy Markdown
Member

Module requirements can now use wildcard maximum versions such as 1.* without module builds or installations failing. Versions remain constrained to the requested major or minor release line, while concrete maximum versions keep their existing behavior.

Fixed: wildcard maximum versions no longer fail module builds

Module manifests can now preserve wildcard maximum-version requirements instead of rejecting them as invalid version values. A requirement such as MaximumVersion = '1.*' remains usable during manifest generation.

Fixed: wildcard maximum versions resolve to the correct release range

Module installation translates wildcard maximum versions into an exclusive upper bound. For example, MinimumVersion = '1.0.0' and MaximumVersion = '1.*' resolve to the range [1.0.0,2.0.0), allowing 1.x releases without admitting 2.x releases. Unsupported wildcard patterns are reported clearly.


Technical details
  • Manifest processing now keeps wildcard maximum versions as strings and only creates a numeric comparison bound for concrete versions.
  • Installation version-spec conversion maps 1.* to the exclusive upper bound 2.0.0 and 1.2.* to 1.3.0; concrete maximum versions remain inclusive.
  • Source test fixtures now exercise a ThreadJob requirement with ModuleVersion = '1.0.0' and MaximumVersion = '1.*'.
  • The branch was synchronized with main; the repository's native Zensical workflow remains unchanged and continues to build directly from zensical.toml.
  • Implementation plan progress: the scoped delivery bug in Build-PSModuleManifest fails when #Requires MaximumVersion uses wildcards #444 is completed by this pull request.
Changed surface Standards checked Framework docs checked Result
.github/actions/** (PowerShell) Naming, functions, action layout Process-PSModule action conventions Aligned
tests/** (PowerShell) Pester fixture conventions Module test repository layout Aligned
Relevant issues (or links)

@MariusStorhaug Marius Storhaug (MariusStorhaug) changed the title Fix wildcard maximum module versions 🪲 [Fix]: Wildcard maximum versions no longer fail module processing Aug 8, 2026
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@github-actions

github-actions Bot commented Aug 8, 2026

Copy link
Copy Markdown

Super-linter summary

Language Validation result
CHECKOV Pass ✅
GITLEAKS Pass ✅
GIT_MERGE_CONFLICT_MARKERS Pass ✅
MARKDOWN Pass ✅
NATURAL_LANGUAGE Pass ✅
POWERSHELL Pass ✅
PRE_COMMIT Pass ✅
SPELL_CODESPELL Pass ✅
TRIVY Pass ✅
YAML Pass ✅

All files and directories linted successfully

For more information, see the GitHub Actions workflow run

Powered by Super-linter

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@MariusStorhaug
Marius Storhaug (MariusStorhaug) marked this pull request as ready for review August 8, 2026 15:20
@MariusStorhaug
Marius Storhaug (MariusStorhaug) merged commit 169c576 into main Aug 8, 2026
72 checks passed
@MariusStorhaug
Marius Storhaug (MariusStorhaug) deleted the fix-wildcard-maximumversion branch August 8, 2026 15:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Build-PSModuleManifest fails when #Requires MaximumVersion uses wildcards

1 participant